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SYSTEM AND METHOD FOR COLLABORATIVE 
AFFINITY MARKETING 

CROSS-REFERENCE TO RELATED APPLICATION 

This patent application claims the benefit of the 
5 filing date of United States Provisional Patent Application 
Serial No. 60/393,157, filed July 2, 2002 and entitled 
"SYSTEM AND METHOD FOR COMMON AFFINITY MARKETING," the 
entire content of which is hereby expressly incorporated by 
reference . 

10 

FIELD OF THE INVENTION 

The present invention relates to a method and system 
for collaborative affinity marketing. More specifically, 
the present invention is directed to a method and system 
15 for collaborative affinity marketing including one or more 
processor (s) , aggregator (s) , participant (s) , and 

merchant (s) . 

BACKGROUND OF THE INVENTION 

20 Merchants of all types depend on attracting new 

customers and securing the repeat business of existing 
customers. They have devised a variety of ways to provide 
incentives for their customers to return repeatedly, 
ultimately becoming loyal customers. 

25 For example, many retail stores (such as grocery 

stores) issue prepaid vouchers , either paper or a plastic 
debit card, referred to as "scrip", which is used by 

consumers as a cash equivalent to purchase products at the 
respective stores. Not-for-profit entities, such as 

30 schools, can purchase scrip in bulk at a discounted price 
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and sell it to affiliated supporters (such as parents of 
the students at the school) at the full price, making a 
profit for the school. 

Alternatively, some merchants contribute a percentage 
5 of the purchase price (possibly, for just certain items) to 
a not-for-profit (aggregator) of the merchant's choice, to 
one that a purchaser (participant) can choose from a list 
provided by the merchant or processor, or one that is 
separately identified by the participants. The term 

10 "aggregator" has been used to describe the entity or 
organization that aggregates some number of participants in 
the program, among other functions. The term "processor" 
is used to describe the central entity or organization that 
processes participant transactions from the merchant and 

15 passes the benefits through to the aggregator, among other 
functions . 

Electronic scrip, developed by eScrip, Inc. of San 
Mateo, CA, is a system in which a supporter registers some 
or all of his debit and credit, ATM cards and grocery 

20 loyalty cards with eScrip and designates the not-for-profit 
entity that will receive the rebate. Monthly payments to 
the not-for-profit entities are made through the EFT 
system. Monthly reports are also provided that allow the 
not-for-profit entities to track funds raised by individual 

25 families on a monthly and year-to-date basis. Purchases 
can be made both on the Internet and at bricks-and-mortar 
vendor locations . There are several drawbacks to the 
electronic scrip system. First, there is no privacy or 
security of information for the participant: the merchant, 

30 aggregator, and credit card company all possess key 
personal and financial information about the participant. 
Secondly, the method is almost entirely dependent on credit 
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or debit transactions in order to track applicable 
purchases and does not apply to payment by any other means 
(with the exception of cash purchases consumers make from 
grocery stores using their loyalty card) . Third, the 
5 method is dependent on the credit or debit card processor 
to provide all information on participant purchases. 

The CardScrip program, introduced by the National 
Scrip Center also supports both Internet and "bricks-and- 
mortar" purchases, employs EFT deposits to entity accounts 

10 and provides a reporting function that allows entity 
tracking of individual families' activities. CardScrip 
suffers from all of the drawbacks of electronic scrip in 
addition to the prerequisite that the participant must 
apply for, and be accepted for, the National Scrip Center 

15 Mastercard and use it in all transactions with merchant 
vendors. This is likely to discourage potential users who 
do not want, cannot use, or cannot qualify for, another 
credit card. 

Moreover, the above processes are not automated, nor 
20 are they integrated in a uniform environment. In addition, 
merchants may not have the time or funds available to 
initiate contact and set up programs for all aggregators 
and participants. Furthermore, merchants must print, 
maintain, secure, and account for their paper-based and 
25 debit card-based scrip offerings. It is also cumbersome 
for the not-f or-prof its to identify merchants, contract 
with them, track how much money to expect from a certain 
merchant and verify the amount that the merchant is 
obligated to pay the not-for-profit. Additionally, 
30 purchasers may have to carry with them scrip from a variety 
of different merchants. Likewise, there is no easy 
mechanism for the purchaser to keep track of how much money 
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the purchaser has contributed to a respective not-for- 
profit through this program. Furthermore, the not-for- 
profit must invest money in carrying a float or inventory 
of available paper scrip for their supporters and those 
5 supporters must pay for scrip up- front and carry their own 
inventory or investment. 

Therefore, there is a need for a more efficient system 
and method for coordinating and managing the entire process 
of the rebating by merchants of portions of consumer 
10 purchases to consumer-designated organizations, hereinafter 
referred to as the Collaborative affinity Marketing Program 
(CAMP) . 

SUMMARY OF THE INVENTION 
15 The system and method of the present invention 

automates and facilitate the identification and setting up 

of the aggregators, participants, and merchants; 

streamlines transactions between specific merchants and 

their respective participants related to particular 
20 aggregators; and reports related information to appropriate 

users in a common, secure environment accessible by these 

users . 

In one embodiment, the present invention is a method 
and system for collaborative affinity marketing including a 

25 processor, an aggregator, a participant, and a merchant. 
The method and system include enrolling with the 
collaborative affinity marketing by the aggregator, 
participant, and merchant; assigning a participant 
identification code to the participant; storing enrollment 

30 information of the aggregator, participant, and merchant; 
providing the participant identification code to the 
merchant when the participant initiates a purchase 
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transaction with the merchant; storing the participant 
identification code and amount of purchase transaction by 
the merchant; sending the stored participant identification 
code, the amount of purchase transaction, and funds 
5 corresponding to a portion of the amount of purchase 
transaction to the processor; and sending a portion of the 
funds received by the processor from the merchant to the 
aggregator. Each processor, aggregator, participant, and 
merchant has a respective right for accessing the stored 

10 information and different portions of the stored 
information are accessible by the processor, aggregator, 
participant, and merchant based on their respective access 
right. Also, the participant is capable of enrolling with 
the collaborative affinity marketing program while 

15 maintaining participant's anonymity. 

The participant may enroll with the processor and 
select the aggregator as a desired aggregator. 
Alternatively, the participant may enroll with the 
aggregator, or be automatically enrolled by the aggregator. 

20 In one embodiment, the present invention is a method 

and system for coordinating and managing rebates by a 
merchant of a portion of a purchase made by a participant 
to an aggregator. The method and system include 

registering with one or more registry by the aggregator, 

25 the participant, and the merchant; generating a participant 
identification code for the participant and a processor 
identification code for the processor; storing registration 
information of the processor, aggregator, participant, and 
merchant; providing the participant identification code and 

30 the processor identification code to the merchant, when the 
participant initiates the purchase with the merchant; 
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storing the participant identification code and amount of 
purchase transaction by the merchant as sale tracking item; 

sending the stored participant identification code, the 
stored amount of purchase transaction, and funds 
5 corresponding to a portion of the amount of purchase 
transaction to the processor based on the stored processor 
identification code; and sending a portion of the funds 
received by the processor from the merchant to the 
aggregator . 

10 

BRIEF DESCRIPTION OF THE DRAWINGS 

The objects, advantages and features of this invention 
will become more apparent from a consideration of the 
following detailed description and the drawings in which: 
15 FIG. 1 is a block diagram of a typical Internet client 

server environment ; 

FIG. 1A is an exemplary flow diagram of a computer 
program executed by one or more computers; 

FIG. 2 is an exemplary flowchart depicting the 
20 Collaborative affinity Marketing Program (CAMP) process and 
its four main entities, according to one embodiment of the 
present invention; 

FIG. 3 is an exemplary process flowchart that gives a 
more detailed presentation of FIG. 2; 
25 FIG. 4 is an exemplary flow chart diagram depicting 

the linkage between the databases and key data classes, or 
entities, according to one embodiment of the present 
invention; 

FIG. 4A is an entity relationship diagram in which 
30 data can be stored and accessed in a logical manner, 
according to one embodiment of the present invention; 



6 



50578/RRT/C995 



FIG. 5 is an exemplary flowchart that shows the 
merchant registration process, according to one embodiment 
of the present invention; 

FIG. 6 is an exemplary flowchart that illustrates the 
5 recording of a key entity, aggregator, participant, or 
merchant, according to one embodiment of the present 
invention; 

FIG. 7 is an exemplary flowchart that depicts the 
adding of a merchant, according to one embodiment of the 
10 present invention; 

FIG. 8 is an exemplary flowchart that shows the adding 
of an aggregator, according to one embodiment of the 
pr e s en t i nven t i on ; 

FIG. 9 is an exemplary flowchart depicting the 
15 acceptance of a periodic merchant report acceptance, 
according to one embodiment of the present invention; 

FIG. 10 is a flowchart showing the process for the 
reconciliation of the periodic merchant report, according 
to one embodiment of the present invention; 
20 FIG. 11 is an exemplary flowchart illustrating 

compilation of statistics in a database and the updating of 
a data warehouse, according to one embodiment of the 
present invention ; 

FIG. 12 is an exemplary flowchart diagram showing the 
25 preparation of aggregator reports and payments to an 
aggregator by the processor, according to one embodiment of 
the present invention; 

FIG. 13 is an exemplary flowchart that shows the setup 
and enrollment of an aggregator, according to one 
30 embodiment of the present invention; 
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FIG. 14 is an exemplary flowchart-depicting setup of a 
participant by an aggregator, according to one embodiment 
of the present invention; 

FIG. 15 is an exemplary flowchart that shows the step- 
5 by-step process of an aggregator preparing individual 
participants packets, according to one embodiment of the 
present invention; 

FIG. 16 is an exemplary flowchart that shows the 
enrollment process for direct participants, according to 
10 one embodiment of the present invention; 

FIG. 17 is an exemplary flowchart illustrating the 
process of a participant making a purchase transaction at a 
merchant, according to one embodiment of the present 
invention; 

15 FIG. 18 is an exemplary flowchart that shows the 

process for the online registration of a merchant on the 
processor web site, according to one embodiment of the 
present invention; 

FIG. 19 is a flowchart showing the process for a 

20 merchant to set up their internal systems to accommodate 
use of the CAMP, an exemplary to one embodiment of the 
present invention ; 

FIG. 2 0 is an exemplary flowchart that depicts the 
steps involved in a merchant's recording a purchase 

25 transaction by a Participant, according to one embodiment 
of the present invention; and 

FIG. 21 is an exemplary flowchart that shows the steps 
undertaken by a merchant for providing a periodic merchant 
report to the processor, according to one embodiment of the 

30 present invention. 



8 



50578/RRT/C995 



DETAIL DESCRIPTION 

The present invention makes the collaborative affinity 
process more cohesive from start to finish. In one 
embodiment, the present invention accomplishes this by an 
5 Internet-based system and method. The Internet-based 
computer system and method of the present invention 
facilitates consistency among all users (aggregators, 
participants, and merchants) by creating a common 
environment in a communication network to guide users on 

10 all sides of the process. Accordingly, the results are 
more accurate, timely, complete, and much easier to 
monitor. Moreover, a greater number of aggregators, 
participants and merchants can participate in this program 
due to the advantages over existing programs and the lack 

15 of their inherent drawbacks . 

In one embodiment, the process of the present 
invention includes registration with a processor (such as a 
web site) as an aggregator, participant, or merchant. The 
registration data are stored in a database on the processor 

20 server (s) and are accessible through the processor's web 
site. Once a respective participant completes a purchase 
with a registered merchant, the participant's ID number is 
recorded along with details of the purchase transaction. 
The respective merchant then sends the related transaction 

25 data to the processor. The transmitted data are then 
processed and reconciled at the processor site and made 
accessible to authorized users, depending on the users' 
access levels. The processor then sends a report to a 
respective aggregator, including all the relevant 

30 information for that aggregator. The processor also makes 
the appropriate payments to respective aggregators. 
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One embodiment of this invention involves the use of 
the internet as a means for signing up merchants, 
aggregators, and participants, for processing their 
transactions and disseminating benefits and information. 
5 The Internet has been popularized by the rapid 
proliferation of the World Wide Web (WWW or Web) . The Web 
links together a variety of computers around the world and 
facilitates access to a tremendous variety of topics in a 
non-sequential web of associations that permits a user to 

10 browse from one topic to another, regardless of the format 
or the order of the topics. Users access and browse the 
Web using a web browser that generally resides and is 
executed on the user's computer. Commercially available 
web browsers such as Netscape's Navigator™ and Microsoft 

15 Internet Explorer™ are very common and accessible by 
personal computer (PC) users. 

The Internet functions based on a client /server model. 
In this model, a client computer communicates with a server 
computer on which information resides, and the client 

20 computer depends on the server to deliver requested 
information and services. These services may involve 
searching for information and sending it back to the 
client, such as when a database on the Web is queried. 
Other examples of these services are the delivery of 

25 information and web pages through a web site, and the 
processing of incoming and outgoing e-mail. Typically, the 
client is a PC user employing a browser to connect to, and 
search, the servers. The servers (also known as hosts) are 
usually more powerful computers that house the data and 

30 databases. The client/server model enables the Web to be 
conceived of act as a limitless file storage medium 
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distributed among thousands of host computers, all of which 
are accessible by any individual PC user. 

FIG. 1 shows a block diagram of a typical Internet 
client server environment used by the processor, 
5 aggregator, participant and merchant according to one 
embodiment of the present invention. PCs 220a-220n, used 
by aggregators, participants, and merchants, are connected 
to the Internet 221 through the communication links 233a- 
233n. Optionally, a local network 234 may serve as the 

10 connection between some of the PCs 22 0a-22 0n, such as the 
PC 220a and the Internet 221. Servers 222a-222m are also 
connected to the Internet 221 through respective 
communication links. Servers 222a-222m include information 
and databases accessible by PCs 220a-220n. In one 

15 embodiment of the present invention, a participant 
database, an aggregator database, an analysis database, a 
merchant database, a transaction history database and a 
data warehouse (shown in FIG. 4) reside on at least one of 
the servers 222a-222m and are accessible by the processor, 

20 aggregators, participants, and merchants using one or more 
of the PCs 220a-220n. 

In one embodiment of the present invention, each of 
the PCs 220a-220n typically includes a central processing 
unit (CPU) 22 3 for processing and managing data, and a 

25 keyboard 224 and a mouse 225 for inputting data. Also 
included in a typical PC are a main memory 227, such as a 
Random Access Memory (RAM) , a video memory 22 8 for storing 
image data, and a mass storage device 231 such as a hard 
disk for storing data and programs. Video data from the 

30 video memory 22 8 is displayed on the CRT 230 by the video 
amplifier 229 under the control of the CPU 223. A 
communication device 232, such as a modem, provides access 
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to the Internet 221. Optionally, one or more of PCs 220a- 
220n may be connected to a local network 234. An 
Input /Output (I/O) device 226 reads data from various data 
sources and outputs data to various data destinations. 
5 Servers (hosts) 222a-222m are also computers and 

typically have architecture similar to the architecture of 
PCs 220a-220n. Generally, servers differ from the PCs in 
that servers can handle multiple telecommunication 
connections at one time. Usually, servers have more 

10 storage and memory capability, and higher-speed processors. 
Some server (host) systems may actually be several 
computers linked together, with each handling incoming web 
page requests. In one embodiment, each server 222a-222m 
has a storage medium 236a-236m, such as a hard disk, a CD 

15 drive or a DVD for loading computer software. When 
software such as that responsible for executing the 
processes in FIGs. 1A and 5-21 is loaded on the server 
222a, off-the-shelf web management software or load- 
balancing software may distribute the different modules of 

20 the software to different servers 222a-222m. Therefore, in 
one embodiment, the computer program responsible for 
executing the present invention resides on one or more 
servers . 

An exemplary web site location 235 is shown on server 
25 222a in FIG. 1. The web site 235 is the user interface 
(UI) for accessing the databases shown in FIG. 4. The web 
site 235 has a unique address that is used by the users to 
access server 222a (in this example) and the web site 
location on the server 222a. The computer software for 
30 executing the processes of the present invention may also 
reside within the web site 235. In one embodiment, servers 
222a-222m are protected by a firewall. The firewall 
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permits a client to communicate with a server system, only 
if the information packet transmitted by the client system 
complies with a security policy set by the server system. 
Thus, the firewall protects the system from unauthorized 
5 users on the Internet. 

FIG. 1A depicts an exemplary flow diagram of a 
computer program executed by one or more of servers 222a- 
222m for one embodiment of the present invention. The 
computer program generates, applies, and maintains related 

10 information about the processor, aggregators, participants, 
and merchants in a web-based environment. A web site 
interface provides the UI to the databases shown in FIG. 4 
for the respective authorized users. In step 701, all the 
related users (aggregators, participants, and merchants) 

15 are enrolled with the processor using the processor's web 
site and employing one or more of the PCs 220a-220n and a 
respective browser. New users may be enrolled with the 
processor at any time. Participants can register either 
directly with the processor, or through an aggregator. 

20 When a purchase is made by a participant, the merchant 

stores the relevant participant's information, including a 
participant ID number, as shown in step 702. In step 703, 
the purchase information of one or more participants is 
transmitted to the processor by the respective merchant. 

25 The processor then processes the data received from a 
plurality of merchants according to each aggregator, each 
participant, and each merchant. The processor then stores 
the processed data in a database, as shown in step 704. In 
step 7 05, the stored data are made available to respective 

30 users with respective access rights. For example, a 
participant is given access only to information related to 
that participant. A merchant is not given any information 
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with regard to the aggregator being supported by any 
particular participant. An aggregator is given access only 
to information related to that aggregator without 
disclosure of any private data (for example, where a 
5 participant shops and how much the participant spends) 
concerning any of the aggregator's participants. This 
scheme ensures the privacy of each user in addition to the 
security provided by the firewall. That is, the processor 
has no knowledge of the identity of any "indirect" 

10 participant enrolled in the program (see discussion in 
following paragraph) . 

FIG. 2 is a data flowchart depicting the Collaborative 
affinity Marketing Program (CAMP) process and its four main 
entities, the processor (10), the aggregator (20), the 

15 participant (30) and the merchant (40) , according to one 
embodiment of the present invention. The processor may 
enroll an aggregator in the CAMP (10a), and the aggregator, 
in turn, and then enrolls a number of participants who are 
in some way affiliated with the aggregator (20a) . These 

20 participants are referred to as "indirect" participants. 
The processor may also enroll participants directly, these 
parties being referred to as "direct" participants (10b) . 
The processor also contracts with and registers a number of 
merchants to participate in the CAMP (10c) . 

25 Participants (either direct or indirect) execute a 

number of purchase transactions with a merchant (3 0a) . The 
merchant then reports these transactions on a periodic 
basis to the processor, at the same time transmitting funds 
or valuable credits that represent a contracted percentage 

30 of the total participants' transactions for the period 
(40a) . The processor combines those funds and remits the 
funds along with detailed reports to the aggregator who 

14 
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enrolled the indirect participant or was designated to 
receive the funds by a direct participant (lOd) . 

Examples of aggregators include many different not- 
for-profit organizations such as houses of worship, private 
5 and public schools, and social response organizations such 
as the Sierra Club, and the like. Further examples can 
fall outside the realm of not-for-profit organizations, 
such as direct marketer organizations, product 
distributors, marketing organizations, online marketers, 
10 etc. 

FIG. 3 is an exemplary process flowchart that provides 
a more detailed depiction of FIG. 2. The processor 
registers each merchant that participates in the CAMP 
(100) . After the initial registration process, the new 

15 merchant's information is entered (100a) in the Record 
Entity Setup process (110) . When the merchant information 
has been verified, the database (500) is updated with the 
new merchant data (110a) and the information is sent to the 
merchant (110b) for the internal Merchant Setup (410). In 

20 one embodiment, merchants have the option of registering 
electronically (400) , for example, signing up through the 
Internet. The registration data are then transmitted 
(400a) to Record Entity Setup (110) and stored (110a) in 
the database (500) . 

25 In one embodiment, aggregators enroll directly with 

the processor to participate in a CAMP (200) . Each 
aggregator has the option of completing their enrollment by 
electronic means, or by transmitting paper enrollment forms 
to the processor (200a) . The processor edits and records 

30 the aggregator enrollment data (110) , and sets up the 
aggregator in the database (110a) . Participant enrollment 
materials are then sent to the aggregator (2 00a) . The 

15 
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aggregator then enrolls (200b) indirect participants (210), 
sending selected information regarding those participants 
to the processor, either electronically or by manually 
submitted forms (210a) . 
5 In one embodiment, participants have the option of 

taking part in a CAMP by enrolling themselves directly with 
the processor (thus, being referred to as direct 
participants (300)), either electronically or manually 
through the use of forms that are submitted to the 

10 processor (300a) . Direct participants indicate in their 
enrollment process the entity (aggregator) that they wish 
to benefit through their participation in the CAMP. 

A participant initiates a Purchase Transaction (310) 
with a registered merchant in person, over the phone, using 

15 the Internet or any other electronic or manual means . 
During the execution of this transaction, the participant 
provides his or her participant ID number to the merchant 
(310a) . This number may be provided to the merchant 
verbally, in writing, or through electronic or any other 

20 means, such as a card or fingerprint of the participant to 
be scanned by the merchant. The participant ID code is 
recorded along with details of the transaction on the 
merchant's manual or automated point-of-sale or sales 
system (420) . In one embodiment, the present invention 

25 provides an easy and efficient way to interface to existing 
merchant data-handling and/or sale tracking systems. In 
this embodiment, the participant ID code is recorded as an 
item in the existing merchant's system and thus eliminating 
the need for a new system or software by the merchant. 

30 Participant ID code maybe a fingerprint or retina scan 

of the participant. Alternatively, the Participant ID code 
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maybe a smart card, a Radio Frequency Identification card 
(RFID) , or similar identification means. 

A smart card includes an embedded integrated circuit 
chip that can be either a microcontroller with internal 
5 memory or a memory chip alone. The card connects to a 
reader through direct physical contact or a remote 
contactless electromagnetic interface. With an embedded 
microprocessor, smart cards have the unique ability to 
store large amounts of data, perform on-card functions 

10 (e.g., encryption and digital signatures) and interact 
intelligently with a smart card reader. A smart card ID 
can combine several ID technologies, including the embedded 
chip, visual security markings, a magnetic stripe, a 
barcode and/or an optical stripe. An RFID card is a 

15 variation of smart card that transmits (and receives) ID 
information via a wireless communication means. 

On a periodic basis, the merchant, combining all 
accumulated participant transactions executed during the 
period (420a) , sends a periodic merchant report (430) to 

20 the processor by manual, electronic or any other means 
(430a) . 

Upon receipt of the periodic merchant report by the 
processor (140) , certain tasks are undertaken to review and 
verify the data provided in the merchant report. For 

25 example, as shown in FIG. 9, the merchant report is 
reviewed and verified against funds received (142) and 
format of the report file is verified (143) . The file is 
then stored in the processor database (144) . The processor 
database (500) tracks merchants, aggregators, participants, 

30 their inter-relationships, and transaction history for each 
of them. 
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Referring back to FIG. 3, after a merchant report has 
been accepted and entered into the database (500) , the 
process continues with the merchant reconciliation (140a 
and 150) , while various validations take place on the data 
5 stored in the database (500) . For example, as shown in 
FIG . 10, merchant and data range are selected for 
reconciliation (151) and then detail transaction data are 
reconciled to a summary transaction data (152). The 
merchant transaction data is then validated by the remit 

10 amount (153) . The merchant remittance amount is then 
validated using the merchant contribution percentage (154) . 
Trends and statistics are computed (155) and stored (155) 
in an Analysis Database 545. The analysis and transaction 
reports are then created (156) . 

15 When new merchant transaction data have been validated 

and reconciled, the data are available in the database 
(500) to be analyzed for trends, statistics and 
demographics. The data are further used for internal 
reports by the processor and are loaded into the Data 

20 Warehouse (555), as shown in FIG. 11. After the Data 
Warehouse (555) has been updated with merchant transactions 
(160) , the data become available for review by the 
aggregator, the participant and the merchant. Each can 
access the raw data and analyses data specific to 

25 transactions that are relevant to them. Aggregators, 
participants and merchants can view data electronically 
(over the Internet, for example) , or can request reports 
from the processor. When new merchant transaction data are 
available in the Data Warehouse (555) , the data are 

30 included in the next aggregator report prepared by the 
processor (160a) . On a periodic basis, the processor 
prepares a report for the aggregator that includes all 
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unreported merchant transaction data since the prior report 
(170) . In conjunction with the issuance of this report, 
the processor effects a payment or transfer of credit to 
the aggregator by manual, electronic or other means. 
5 FIG. 4 depicts the linkage between the databases (500, 

555) and key data classes, or entities. After merchants 
are registered with the system of the present invention 
(100, 400) and then recorded (110), their setup data are 
entered (510, 520) and stored in Merchant Data (540) within 

10 the database (500) (500c) . After an aggregator is enrolled 
(200) and recorded in step 110, the aggregator data are 
entered and stored (510, 520) in Aggregator Data (535) 
within the database (500) (500b) . After participants are 
set up in the CAMP system (210, 300) , their data are 

15 recorded (110) and entered and stored (510, 520) in the 
Participant Data (530) within the database (500) (500a) . 

In the Periodic Merchant Report Acceptance (140) 
process, merchant transactions data are stored in 
Transaction History Data (550) within the database (500) 

20 (500e) . As part of the Merchant Reconciliation, all 
transactional data and the manner in which they relate to 
merchants, aggregators and participants are analyzed with 
respect to trends, statistics and demographics and stored 
in Analysis Data (545) within the database (500) (500d) . 

25 In the Aggregator Reporting and Payment Process (170) , 

the Data Warehouse (555) facility is updated with 
transaction data, trends, statistics and demographics 
(500f) and made available to CAMP entities through database 
inquiry and reports requested through Web site Interface 

30 (510) and Management Interface (520) (510a, 520a). 
Although Participant Data, Aggregator Data, Merchant Data, 
Analysis Data, and Transaction History Data are part of the 
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processor database (500) in the above described exemplary 
embodiment, one skilled in the art should realize that one 
or more of the above-mentioned data may reside in one or 
more separate databases . 
5 FIG. 4a is an Entity Relationship diagram that depicts 

one embodiment of the present invention in which data can 
be stored and accessed in a logical manner. The connecting 
lines provide definitions of each of the logical 
relationships among and between the four main entities of 

10 the CAMP, as well as other supporting data entities. The 
Aggregator Data (535) table provides basic Aggregator 
information. Because aggregators can be associated with 
one another, the Aggregator Relationship (536) table 
provides for a series of parent-child (parent-subsidiary) 

15 relationships. The Participant Allocation (531) table 
provides for a many-to-one relationship between 
participants and aggregators, enabling direct participants 
to allocate any portion of the funds or credits in the 
Reporting and Net Funds process (lOd) between or among 

20 multiple aggregators . 

The Participant Data (530) table provides for the 
storage of essential information regarding a participant. 
Several other tables provide for multiple relationships 
between this Participant Data (530) table and other data 

25 entities in the database. The Participant Relationship 
(532) table provides for a series of parent-child (parent- 
subsidiary) relationships for associating related 
participants . 

The Transaction History Data (550) table and the 
30 related Transaction History Summary (551) table provide for 
storage of historical data regarding a participant or 
series of participants associated by the parent-child 
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relationship defined in the Participant Relationship (532) 
table. The Transaction History Data (550) table and the 
related Transaction History Summary (551) table also 
provide for the storage of historical data regarding an 
5 aggregator or related aggregators, as defined in the 
Aggregator Relationship (536) table. 

The Merchant Relationship (544) table provides for a 
series of parent-child (parent-subsidiary) relationships 
for associating related merchants. The Merchant Data (540) 

10 table provides for the storage of essential information 
regarding a merchant and the Contract (541) table provides 
additional information on the merchant and their 
contractual agreement with the processor. Several other 
tables provide for multiple relationships between this 

15 Merchant Data (540) table and other location tables in the 
database. The Location (542) table provides for multiple 
locations of any merchant. The existence of the two region 
tables (543, 502) and their relationship to the Location 
(542) table, the Merchant Relationship (544) table and the 

20 Merchant Data (540) table, provides the ability to report 
by merchant location, merchant region or processor region. 

Tables 502, 542, 543 and 534 and their 
interrelationships, as well as their relationships with 
Participant Data (530) and Merchant Data (540) , provide for 

25 a comprehensive statistical analysis and reporting on the 
Transaction History Summary (551) and Transaction History 
Data (550) by any of the afore-mentioned tables. The 
relationship between participants and aggregators, 
described above, provides for any of the above reporting by 

30 participant and by aggregator. The Contact (501) table is 
a common data-store for contact of any type, whether 
aggregator, participant or merchant. 
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FIG. 5 is an exemplary flowchart that shows the 
merchant registration process (100) . Merchant registration 
materials are received and compiled (101) and undergo 
review (102), entry in the system (103), and editing and 
5 validation of data (104) . If data omissions or errors 
exist, they are reported (104a) to the user for correction 
and re-processing (102, 103 and 104). After data has been 
validated, merchant status becomes a pre-registered, all 
data is stored in the database (500) and a merchant 

10 contract is printed (106) . Merchant Setup materials 
including registration information, documentation and 
materials, are then combined with the merchant contract, 
(106) assembled (107) , and submitted to the merchant for 
review and signature. 

15 FIG. 6 is an exemplary flowchart illustrating the 

recording of a key entity (110), aggregator (20), 
participant (30), or merchant (40) according to one 
embodiment of the present invention. Setup materials are 
received from the merchant registration process (100) , an 

20 aggregator registration (200) , a direct participant 
registration (300) , or merchant (400) registration and 
reviewed for completeness (111) . 

If the materials pertain to a direct participant, 
detailed participant data is entered (112), and updated in 

25 database (500) . If the materials pertain to an aggregator 
(200), detailed aggregator data is entered (130), 
participant packets are selected (113) for the requested 
number of indirect supporters by the aggregator, and all 
data is stored in database (500) . If the materials pertain 

30 to a merchant (400) , merchant detailed data is added (12 0) , 
and updated in database (500) . The applicable confirmation 
and notification is printed (114) and all materials 
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relevant to the aggregator (20), participant (30), or 
merchant (40) are compiled and submitted to that entity 
(115) . 

FIG. 7 is a flowchart that depicts the adding of a 
5 merchant (120) , according to one embodiment of the present 
invention. The processor (10) receives (121) a signed 
contract (106 in FIG. 5) from the merchant (40) . The 
contract is then reviewed for completeness (122) and 
contract details are recorded and if complete, the contract 

10 is approved (123), the data is further edited and validated 
(12 4) against the database (500) . If there are any errors 
or omissions, they are reported (124a) back to the user for 
correction and re-entry. If there are no errors or 
omissions, the merchant is set with a "registered" status 

15 (12 5) and contract signing and status are recorded (126) in 
database (500) . 

FIG. 8 is an exemplary flowchart that shows the adding 
of an aggregator (130), according to one embodiment of the 
present invention. The processor (10) receives setup 

20 materials and completed enrollment form (131) from the 
aggregator (20) and review the materials and form for 
completeness (132). Aggregator data is entered (133), and 
the data is further edited and validated (134) against the 
database (500) . If there are any errors or omissions they 

25 are reported (134a) back to the user for correction and re- 
entry. If there are no errors or omissions, the data is 
recorded in database (500) . Participant identification 
(ID) numbers (codes) are assigned to the aggregator (135) 
and recorded in the database (500) . All other aggregator 

30 data is also recorded (136) in the database (500) . 

FIG. 9 is an exemplary flowchart depicting the 
acceptance of a periodic merchant report. The periodic 
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merchant report is received in electronic format (141) , 
according to one embodiment of the present invention. The 
report can be received in by any number of different means, 
including paper, email, diskette, or CD. Subsequently the 
5 report is reviewed and verified against the funds received 
from merchant (142), and the format of the electronic 
report is verified or entered in the system (143) . The 
merchant report file is imported (144) into database (500) 
and the database is updated. The processor database (500) 

10 tracks merchants, aggregator and participants, their inter- 
relationships and transaction history for each entity. 

FIG. 10 is a flowchart showing the process for the 
reconciliation of the Periodic Merchant Report (150) , 
according to one embodiment of the present invention. The 

15 reconciliation process is initiated by selecting a merchant 
(40) and an applicable date range to be reconciled (151) . 
Detail transaction data is reconciled to summary 
transaction data (152) by comparing the detail line items 
and amounts to the summary data by participant and merchant 

20 location. Transactions are then validated against merchant 
remittance amounts (153). Merchant summary, detail and 
financial information are also validated against the 
contract percentage from the database (500) among merchant 
data (540) (154) . Statistical data relating to 

25 transactions and trends are stored in the database (500) 
among analysis data (545) (155). Analysis and transaction 
reports and statistics by merchant, aggregator and 
participant are computed (156) and reports created (157) . 

FIG. 11 is a flowchart illustrating compilation of 

30 statistics in a database (500) and the updating of a data 
warehouse (555) (170) , according to one embodiment of the 
present invention. The process is initiated by the receipt 
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and compilation (161) . A data rollup process (162) is 
performed on data in database (500) to index totals and 
sort data into an efficient format for warehousing. 
Additional statistics and key indices are compiled (163), 
5 and additional data integrity validation (164) takes place 
on the database (500) to ensure against data anomalies. 
Next the rollups, statistics, computation, and indices 
(162, 163, and 164) are updated (165) and stored in the 
data warehouse (555) . 

10 FIG. 12 is an exemplary flowchart diagram showing the 

preparation of aggregator reports and payments (17 0) to an 
aggregator (20) by the processor (10) . The process is 
initiated by selecting an aggregator or a group of 
aggregators for reporting (171) . An extract process is run 

15 selecting aggregator (172) data from the database (500) and 
data warehouse (555) . Aggregator reports (173) are then 
generated which may be ordered by key indices and including 
relevant statistics. According to one embodiment of the 
present invention, the reports can be generated in 

20 electronic or hardcopy format. When reports are produced, 
the aggregators are selected (174) for payment approval and 
undergo the payment approval process (175) . All 
aggregators approved for payment have payment requests 
(176) processed and checks printed (177). According to one 

25 embodiment of the present invention, an electronic funds 
transfer (178) or other electronic means of payment can be 
used. 

FIG. 13 is an exemplary flowchart that shows the setup 
and enrollment (200) of an aggregator. The aggregator 
30 receives the enrollment forms from the processor (201) , 
reviews the forms and organizes (202) the necessary 
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information and documentation to complete the enrollment 





process . 


The aggregator enrollment data includes: 




1. 


Name /Address /Key Contacts 




2. 


Member Type 


5 


3. 


Number of Members 




4. 


Annual Membership Growth Rate 




5. 


Website URL 




6. 


Affiliations 




7. 


Parent Organization 


10 


8. 


Bank Information 




9. 


Tax ID 




10. 


Copy of 501(c)(3) Certificate 




11. 


Referred by Contact 




12. 


Processor Contact 


15 


13. 


"How did you hear about us" indicator 



An aggregator has the option of completing the 
enrollment online through the processor website (204) or by 
completing the enrollment forms manually (203) and 
submitting them to the processor. If the aggregator uses 

20 the online option, he/she completes enrollment online (204) 
and the data is edited and validated (205) . The aggregator 
is then advised of any errors or missing information 
(205a) . When the enrollment is complete the data is stored 
in database (500) . Whether the enrollment is accomplished 

25 manually or by way of the website, the aggregator signs the 
forms and selects a voided check and a copy of a 
certification (206) and sends the enrollment forms and 
other documentation (207) to the processor. 

FIG. 14 is an exemplary flowchart depicting setup of a 

30 participant (210) by an aggregator, according to one 
embodiment of the present invention. The aggregator 
receives the setup packets (211) from the processor upon a 
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successful enrollment (200) . The aggregator assigns each 
participant a participant ID number (code) (212) and 
prepares the individual participant packets (220) for 
distribution to the respective participants. After the 
5 participants have been assigned (212) ID numbers and the 
packets are prepared (220) , the aggregator makes a record 
of participants with their corresponding ID numbers. 

This is accomplished by updating aggregator's own 
manual system (213) or by updating aggregator's own 

10 automated membership system (214) and by storing the data 
in a local participant database (215) provided by the 
processor. The processor database (500) is updated (216) 
with participant ID only by communicating with the local 
participant identification database (215), printing a 

15 report and sending it to the processor, by entering the 
data using the online website at the processor, or by 
sending an electronic file with the data to the processor. 
The data transmitted to the processor includes the home zip 
code of the participant and the ID number assigned. The 

20 aggregator then sends the assigned packet to each 
participant (217) . 

FIG. 15 is an exemplary flowchart that illustrating 
the step-by-step process of an aggregator preparing 
individual participants packets (280), according to one 

25 embodiment of the present invention. Custom-designed 
packaging to facilitate manual processing of Participant 
Packets are provided by the processor. Envelopes are pre- 
stuffed with necessary materials for the participants and 
Tabs with peel-off Participant ID labels and the tabs 

30 prevent closure of envelope prior to their removal and use 
in the process. Aggregators need not keep track of which 
participant has been assigned which identification number 
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but it is in their best interest to do so because this 
provides them with the ability to track which participant 
is generating funds. 

In one embodiment of the present invention, the 
5 aggregator prepares an internally generated participant 
report (281) and prepares internally generated participant 
address labels (282) from the member records. The 
aggregator than tears two identification number labels 
(283) from the top of the participant packet; affixes one 

10 label (e.g., blue) to the front of the packet (284) and a 
second label (285) (e.g., red) to the membership report 
(281) . They affix (286) the membership address label (282) 
to the participant packet. The aggregator then completes 
packets for all participants and distributes (287) them to 

15 the assigned participant by mail or any other means. 

FIG. 16 is an exemplary flowchart that shows the 
enrollment process (300) for direct participants according 
to one embodiment of the present invention. A direct 
participant selects the online website (301) provided by 

20 the processor and selects the function to add himself as a 
direct participant (302) . The participant enters his 
personal information (303) at the website. The information 
is then edited and validated (304) . Any errors or 
omissions are reported back to the participant by way of 

25 the website (304a) for re-entry and re-processing. The 
direct participant selects (305) one or more aggregators 
that he wishes to receive the funds generated by his 
activity; the direct participant may request a new 
aggregator to be contacted for enrollment. The new direct 

30 participant is assigned an identification number and their 
participant data (306) is stored in the database (500) . 
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Next, the processor sends (307) the direct participant a 
participant packet. 

FIG. 17 is an exemplary flowchart illustrating the 
process of a participant making a purchase transaction 
5 (310) at a merchant. The participant initiates a purchase 
transaction at the merchant (311) and provides her 
participant ID (312) to the merchant during the 
transaction. According to one embodiment of the present 
invention, the participant ID can be provided through the 

10 use of a bar coded card, bar coded label, or magnetic 
strip. The participant ID may be cross-referenced by the 
merchant to the participant phone number or any other 
personal identification number or merchant tracking number 
in use by the merchants for tracking their customers. The 

15 identification number could be entered by the participant 
while making an on-line purchase on the internet at the 
website provided by the merchant. 

FIG. 18 is an exemplary flowchart that shows a process 
for the online registration of a merchant (400) on the 

20 processor web site. The merchant selects the website 
provided by the processor and completes the registration 
(401) information. The data is edited and validated (402) 
and any registration data errors or omissions are reported 
back to the user on the website (402a) for correction, re- 

25 entry and re-processing. Once entered successfully, the 
merchant status is set to pre-registered (403), the 
information is stored in database (500) , and a merchant 
contract (404) is printed. Each merchant should indicate 
their percentage participation, sign the contract, and 

30 assemble other documents or information required to be 
submitted with the contract (405) . The merchant submits 
the contract to the processor (406) 
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FIG. 19 is an exemplary flowchart showing the process 
for a merchant to set up (410) her internal systems to 
accommodate use of the CAMP, according to one embodiment of 
the present invention. The merchant receives the processor 
5 identification number when she has successfully registered 
(400) and has been set (410) up in the processor database 
(500) . The processor identification number is the first of 
two segments that comprise the participant identification 
number of which, the first is significant for 

10 identification of the processor and the second segment 
identifies the participant ID number. 

The merchant prepares the necessary information for 
entry in the merchant's customer tracking, merchandise 
tracking, or service tracking system (411) . The merchant 

15 enters the new item tracking number (412) and if necessary 
for her system, sets it to a zero cost and sales price 
(413), turn off inventory tracking (414), and identifies 
the first segment as primary tracking number (415) . The 
merchant tracking system is then updated with the new 

20 information (416) . The Participant ID number is not 
necessary for tracking transactions in the merchant 
transaction tracking system, but it is stored with each 
transaction to facilitate the identification of the 
individual participant when reporting activity (430) to the 

25 processor. According to one embodiment of the present 
invention, the processor identification and participant ID 
numbers are Universal Product Codes or bar codes and are 
stored in a merchant point-of-sale system as an inventory 
or membership number. 

30 FIG. 2 0 is an exemplary flowchart that depicts the 

steps involved in a recording a purchase transaction (420) 
by a merchant's system, according to one embodiment of the 
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present invention. The participant provides her 

participant ID to merchant during a purchase transaction 
(421) . The merchant records the participant ID when 
processing the transaction in their sales tracking system, 
5 such as "scanning" the participant ID as a bar code or 
11 swipes" a magnetic strip with the ID encoded. The 
participant ID is stored in the merchant tracking system 
(423) with relevant transaction data. The merchant 

tracking system may include a database; storing transaction 

10 detail data with unique processor and participant ID 
numbers that identifies that transaction as part of the 
CAMP. This first segment is significant to the merchant 
for tracking transactions. The second segment is 

indicative data for the merchant and only passed to the 

15 processor as part of the merchant reporting (430) process. 

FIG. 21 is an exemplary flowchart illustrating the 
steps undertaken by a merchant for providing a periodic 
merchant report (430) to the processor, according to one 
embodiment of the present invention. The merchant 

20 reporting process is initiated (431) by the merchant on a 
periodic basis as defined in the merchant contract (404) . 
A report or database query tool is initiated to start a 
data extraction (432) process to retrieve the relevant data 
from the merchant tracking system and/or database (424) and 

25 provide the necessary data for reporting CAMP activity at 
the merchant. The applicable date range is selected (433) 
by the merchant and the data is extracted (434) and 
inserted into an electronic extract file (436) . The 
electronic extract file is transmitted to the processor 

30 (438) as the periodic report. The merchant computes (435) 
the correct remittance amount based on the total amount 
stored in the extracted file and sends funds or some 
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financial credits (437) to the processor by check or 
electronic funds transfer. 

It will be recognized by those skilled in the art that 
various modifications may be made to the illustrated and 
5 other embodiments of the invention described above, without 
departing from the broad inventive scope thereof. It will 
be understood therefore that the invention is not limited 
to the particular embodiments or arrangements disclosed, 
but is rather intended to cover any changes, adaptations or 
10 modifications which are within the scope and spirit of the 
invention as defined by the appended claims. 



32 



